Network Address Translation (NAT) is an Internet technology that was originally developed to work around the growing scarcity of Internet Protocol (IP) addresses on the Internet. The current, and most widely used, Internet Protocol (IPv4) supports more than four billion addresses. However, because of inefficient allocation of addresses, routing constraints, and the Internet's phenomenal growth, this number has proven insufficient. The NAT solution is to use private addresses on a company's (or homeowner's) internal network and only convert those internal addresses to globally routable IP addresses when communicating through a gateway (e.g., router, firewall, other switching or routing device) to hosts (other computers/servers) on the Internet. In some applications, hosts currently communicating will get their own globally routable IP address, while in other applications, as few as one globally routable IP address may be used for multiple internal hosts. Ideally, this translation will be invisible to the underlying networking applications and protocols. NAT functionality can also be exploited for its security features (internal IP addresses are effectively “hidden” to the external world) and has been employed in session redirection and load balancing.
There are many products available today that employ NAT functionality, including routers for business and home use, firewalls, and Internet/residential gateways. Some computer operating systems also implement NAT functionality so that a server or workstation running such an operating system can act as a NAT-enabled software router or firewall. Applications of NAT have been focused on address translations based on network structure, resource availability, and simple application requirements.
FIG. 1 illustrates an exemplary use of a NAT map (functionality) 100 within a NAT router 110 connecting an internal network 120 to the Internet 130. The internal network 120 includes the NAT router 110, an application server 140 and a file server 150. External users 160, 170 can connect to the internal network 120 via the Internet 130. The NAT map 100 includes a list of external IP addresses 180 and a list of internal IP addresses 190.
As is understood in the prior art, the first user 160 transmits packets to the externally known IP address for the application server 140 (196.28.43.2). With no regard for who the user is or what the resource is, the NAT router 110 receives the packets containing the externally known destination IP address 180 (196.28.43.2) and utilizes the NAT map 100 to translate the external address (196.28.43.2) to a corresponding internal IP address (10.33.96.5) 190 and routes the packets accordingly. The second user 170 sends packets to the file server 150 (using external IP address 196.29.74.4) and the NAT router 110 translates the external address to the internal IP address (10.33.96.9) and forwards to the file server 150. If the application server 140 or file server 150 communicates with an external user, the NAT router 110 utilizes the NAT map 100 to translate the source address from the internal IP address 190 (10.33.96.5 and 10.33.96.9 respectively) to the externally known IP address 180 (196.28.43.2 and 196.29.74.4) prior to forwarding the packets externally. The external users therefore do not know the internal IP addresses. Although as illustrated in FIG. 1 the user's addresses are not translated, the NAT map 100 may optionally perform user address translation.
Session flow, also referred to herein as flow, is well known to those skilled in the art and is described in detail in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2663, which is incorporated herein by reference. Session flow is a combination of inbound and outbound packets that form part of a session initiated in one direction. Packet flow is defined in RFC 2663 as the direction in which the packet has traveled with reference to a network interface. As an example, a session (session flow) initiated by a user on a server for telnet would consist of packet flows in both the inbound and outbound directions.
As network applications and Web application services have proliferated and corporate networks have become more distributed, there has been a growing need for more flexibility in address translation functionality. NAT is a process in which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation (NAPT) is a method by which many network addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. NAPT works well to share a single globally routable IP address when an internal user initiates the contact and receives a reply on the same port. The processes of NAT and NAPT are well known to those skilled in the art and are described in detail in ETF document RFC 3022, which is incorporated herein by reference. However, when multiple applications using the same well-known port (such as TCP port 443 for secure socket layer) are placed behind an NAPT enabled device some of the applications may become inoperative for inbound flows.
Other features of NAT have been developed, including the use of NATs for load sharing, where a session load can be distributed across a pool of servers, instead of directed to a single server. The use of NATs for load sharing is described in the IEETF document RFC 2391, which is incorporated herein by reference. A type of NAT has been developed for interfacing between end-nodes using version 6 of the Internet protocol (V6) trying to communicate with end-nodes using version 4 (V4) and vice versa. This type of Network Address Translation—Protocol Translation (NAT-PT) is described in RFC 2766, which is incorporated by reference herein.
The prior art systems essentially use address maps to provide address translations regardless of who the client is and what the service is. This limited flexibility results in unrestricted user access and uniform address translation. What is needed is a way to create and adjust network address translation configurations based on user and resource-specific network policies. Such capability would result in higher security based on user authorization, greater control of network resources and the general ability to vary network address translation for a wide range of purposes.